System and method for connected metering

ABSTRACT

A universal metering cabinet (UMC) apparatus comprises an input/output (I/O) interface configured to receive at least two data streams, each of the at least two data streams received from one of at least two sensors, and each of the at least two data streams having a different connectivity protocol. The UMC further comprises a customizable programmable interface coupled with the I/O interface and configured to convert the connectivity protocol of each of the at least two data streams into a same uniform connectivity protocol. A method comprises receiving, from the UMC, at least one data stream that includes data from at least two sensors, and receiving, from at least one server, data related to an environment around the at least two sensors. The method further comprises performing data cleansing on the data stream and the data to generate validated data and performing prognostic modeling on the validated data.

TECHNICAL FIELD

This disclosure relates generally to metering systems. Morespecifically, this disclosure relates to systems and methods forconnected metering to provide advanced analytics and maintenanceprognostics.

BACKGROUND

Industrial process control and automation systems are routinely used toautomate large and complex industrial processes. These types of systemstypically include meters to monitor the industrial processes and provideinformation to the business, for example to allow for auditing of theindustrial processes and to monitor for failures in the industrialprocesses. Additionally, data from the meters may be used to estimatemaintenance and calibration schedules of the meters of the metersthemselves.

SUMMARY

This disclosure provides systems and methods for connected metering toprovide advanced analytics and maintenance prognostics.

In a first embodiment, a universal metering cabinet (UMC) apparatusincludes at least one input/output (I/O) interface configured to receiveat least two data streams, each of the at least two data streamsreceived from one of at least two sensors, and each of the at least twodata streams having a different connectivity protocol. The UMC apparatusfurther comprises a customizable programmable interface coupled with theat least one I/O interface and configured to convert the connectivityprotocol of each of the at least two data streams into a same uniformconnectivity protocol.

In a second embodiment, a method includes receiving, at a universalmetering cabinet, at least two data streams from at least two sensors,each data stream having a connectivity protocol, each data stream havinga connectivity protocol. The method further includes converting, using acustomizable programmable interface, the connectivity protocol of eachof the received data streams into a same uniform connectivity protocol.

In a third embodiment, a method includes receiving at least one datastream that includes data from at least two sensors and receiving, fromat least one server, data related to an environment around the at leasttwo sensors. The method further includes performing data cleansing ordata wrangling on the data stream and the data to generate validateddata and performing prognostic modeling on the validated data.

Other technical features may be readily apparent to one skilled in theart from the following figures, descriptions, and claims.

BRIEF DESCRIPTION OF THE DRAWINGS

For a more complete understanding of this disclosure, reference is nowmade to the following description, taken in conjunction with theaccompanying drawings, in which:

FIG. 1 illustrates an example industrial process control and automationsystem according to this disclosure;

FIG. 2 illustrates an example UMC according to this disclosure;

FIG. 3 illustrates an example UMC connected to a metering systemaccording to this disclosure;

FIG. 4 illustrates an example process flow using the UMC to send data tothe cloud and perform data cleansing, data wrangling, measurementvalidation, and prognostication according to this disclosure;

FIG. 5 illustrates a mesh connected metering ecosystem according to thisdisclosure; and

FIG. 6 illustrates an example method of a connected metering processaccording to this disclosure.

DETAILED DESCRIPTION

FIGS. 1 through 6, discussed below, and the various embodiments used todescribe the principles of the present invention in this patent documentare by way of illustration only and should not be construed in any wayto limit the scope of the invention. Those skilled in the art willunderstand that the principles of the invention may be implemented inany type of suitably arranged device or system.

Embodiments of this disclosure contemplate that metering accuracy andreliability in industrial processes directly influences margins due tothe effects on maintenance costs, process downtime, and accuracy ofaudits of processes. Cloud enabled connectivity across various meters(or sensors) in a system, combined with data cleansing or data wrangling(i.e., conversion of disparate data into compatible data types) allowdata analysis that can enable a user to, for example, validatemeasurements or predict a problem in advance of a failure. Historicaldata and information being captured can be used as a basis to extend thecalibration intervals of meters, specified by regulatory authorities,and can be used to prove near real-time condition-based uncertaintymeasurement to legal metrology standards. In legal metrology,measurement uncertainty is a non-negative parameter characterizing thedispersion of values attributed to a measured quantity. All measurementsare subject to uncertainty, and a measurement is not considered completeuntil it is accompanied by a statement of associated uncertainty(e.g., + or −X%).

Embodiments of this disclosure include a connected metering solutionthat enables near real-time detailed data analysis for making betterdecisions regarding maintenance, recalibration, and reporting ofmismeasurements to regulatory authorities. Relevant data is available atprimary and secondary meters in the field, and a connected meteringapproach makes it possible to take this disparate, isolated informationand make it useful. The connected metering solution regularly pulls andstores relevant raw data to provide prognostics (i.e., event prediction)with a real-time view of metering and related in-situ near real-timecondition-based uncertainty. Condition based monitoring (CBM) of themeters is automated, and problems can be predicted before they occur,keeping measurement uncertainty as low as possible while improving onthe typical preventative maintenance process that requires spot checksof working equipment or reactive responses to failures, both of whichresult in wasted resources.

Furthermore, meters or sensors are prone to data leakage, which is theunintended loss of information. Data leakage can occur when data isdiscarded, for example, when an employee tasked with monitoring themeter considers the data unimportant or simply does not see or recordthe data, or when the data is converted to a different format before itis analyzed, and the original is discarded. Data leakage can also occurwhen self-diagnostics capabilities of the meter or sensor are notconnected, or when the data collection system is analog-based and cannotprocess digital protocols. A connected metering solution collectssubstantially all data from the meter, reducing or eliminating dataleakage.

Embodiments of this disclosure contemplate using data from the connectedmetering solution to construct a virtual meter (or digital twin) of aphysical meter. Simulation and testing can be performed on the virtualmeter to analyze the condition of the meter. This enables failureprognostics and determination of calibration status for the physicalmeter by performing tests on a digital twin of the physical meterwithout having to take the physical meter offline. The data provided bythe connected metering solution allows the digital twin of the physicalmeter to approximate the physical meter closely enough that test resultson the digital twin are applicable to the physical meter.

Furthermore, embodiments of this disclosure recognize that while CBMpackages provide an attempt to take a holistic approach to monitoringthe system health of a metering system, such as a flow metering system,there is no standard defining CBM packages, and each installed instanceof a CBM package is somewhat unique. Indeed, interpreting the datacollected and reported by typical CBM packages is a job for anexperienced metering engineer despite advancements towards a “trafficlight” system of output that uses a scheme of red, orange, and green toindicate the condition (or health) of a meter itself. Furthermore,typical CBM packages do not provide uncertainty analysis for the metersbeing monitored (for example, analysis of changes in uncertainty of aflow meter's bulk flowrate). Uncertainty analysis is desirable forcompliance with legal metrology standards, and because not maintainingan uncertainty budget can expose a plant operator to measurement biaserrors.

There are many individual diagnostic parameters analyzed in a CBMpackage for which the impact of each, or the sum of a number ofdiagnostics, is not directly attributable to measurement uncertainty.For example, a meter's diagnostics are often influenced by fluctuationsin the process in which the meter is located, and such fluctuations arenot accounted for in diagnostics reporting of the meter, making itdifficult to determine whether a change in the status of the meter isdue to a fault in the meter or a change in the process external to themeter (whether intended or unintended). Even if a measurand is reportedto the CBM that relates to a change in the metering output, it can bedifficult to determine the cause of fluctuation in the metering output.

This disclosure contemplates that advanced analytics for both a meter aswell as a process in which the meter is located are needed to providecondition-based uncertainty analysis for the meter, and that connectedmetering solutions of this disclosure are needed to provide the data forsuch analytics. Condition-based uncertainty analysis recognizes theinfluences that are typically seen at a metering point of measurementand are specific to a measuring device (i.e., a meter or sensor). Forexample, in an orifice meter placed into a natural gas process,influences on uncertainty include: bulk flow rate (including rateprofile changes), in-use-streams (open and closed), differentialpressure, temperature, pressure, composition, measurement drift orcalibration interval, and test tolerances.

It is not unusual for multiple meters to be used to measure the samequantity, and measurement bias error can occur for any given sensor. Ameasurement bias error occurs when the source measured by the meter isbiased in some way. For example, in an ultrasonic meter, a measurementbias error can occur due to build-up or fouling on wetted transducerfaces of the meter. In a differential pressure meter, plugging may occurto cause a measurement bias error. In thermal devices, liquid dropletscan cause heat loss to evaporation, resulting in a measurement biaserror. In natural gas systems, meters are generally affected by gasdensity and temperature distortions (e.g., differences between thetemperature profile and the velocity profile of the gas).

A connected metering system (using a UMC) combined with a CBM package toprovide near real-time condition-based uncertainty analysis provides a“technical audit” of the target measurement by validating (orinvalidating) the measurement. That is, it addresses the fact that whenwe take a measurement of a measurand, the result is not the “true” valueof the measurand, but an estimate of the true value, due to theabove-described uncertainty. Uncertainty analysis provides an audit ofdegree of certainty of the measurement, and allows a plant operator totake actions to reduce uncertainties as low as possible, for example bycalibrating meters or adjusting processes. As part of this process, thenear real-time condition-based uncertainty analysis provides informationthat can be used to perform prognostics on meters to predict failurestates before they occur.

FIG. 1 illustrates an example industrial process control and automationsystem 100 according to this disclosure. As shown in FIG. 1, the system100 includes various components that facilitate production or processingof at least one product or other material. For instance, the system 100is used here to facilitate control over components in one or multipleplants 101 a-101 n. Each plant 101 a-101 n represents one or moreprocessing facilities (or one or more portions thereof), such as one ormore manufacturing facilities for producing at least one product orother material. In general, each plant 101 a-101 n can implement one ormore processes, and the plants 101 a-101 n can individually orcollectively be referred to as a process system. A process systemgenerally represents any system or portion thereof configured to processone or more products or other materials in some manner

In FIG. 1, the system 100 is implemented using the Purdue model ofprocess control. In the Purdue model, “Level 0” may include one or moresensors 102 and one or more actuators 103. The sensors 102 and actuators103 represent components in a process system that may perform any of awide variety of functions. For example, the sensors 102 could measure awide variety of characteristics in the process system, such astemperature, pressure, or flow rate. In addition, the actuators 103could alter a wide variety of characteristics in the process system. Thesensors 102 and actuators 103 could represent any other or additionalcomponents in any suitable process system. Each of the sensors 102includes any suitable structure for measuring one or morecharacteristics in a process system. Each of the actuators 103 includesany suitable structure for operating on or affecting one or moreconditions in a process system.

Universal metering cabinets (UMCs) 104 couple directly to sensors 102 tocollect metering data and send it to the cloud 142 (for example, to aserver within the cloud 142) for data cleansing, data wrangling, andanalysis, as will be further described below. In some embodiments, UMCs104 additionally collect environmental data relevant to the meter foruse in the data analysis, such as diagnostic information from sensors102, and information on other measurands in the system monitored bysensors 102. For example, in a gas metering system the UMC 104 couldreceive data from target sensors 102 that are flow meters, as well asdata from each of pressure sensors, temperature sensors, and levelswithin the environment of the flow meters. UMCs 104 are compatible withpre-existing infrastructure and may be installed with sensors 102 thatwere not designed with the UMC 104 in mind. In some embodiments, one UMC104 may be connected with multiple sensors 102, and may act as amultiplexer (MUX) to the cloud 142. The UMCs 104 additionally connect tothe historian 141, described further below, such that data from thehistorian 141 can be combined with data from the sensors 102 foranalysis.

Redundant networks 105 are coupled to the sensors 102 (via the UMCs 104)and actuators 103. The networks 105 facilitate interaction with thesensors 102 and actuators 103. For example, the networks 105 couldtransport measurement data from the sensors 102 and provide controlsignals to the actuators 103. The networks 105 could represent anysuitable redundant networks. As particular examples, the networks 105could represent redundant IEC-61850, IEC-62439, Ethernet/IP (EIP), orMODBUS/TCP networks. The networks 105 can have any suitableconfiguration, such as a parallel or ring topology. The networks 105 areoften referred to as “industrial control” networks since these networkstransport data used directly to control the underlying process system.

In the Purdue model, “Level 1” includes one or more controller groups106, which are coupled to the networks 105. Among other things, eachcontroller group 106 may use the measurements from one or more sensors102 to control the operation of one or more actuators 103. Eachcontroller in the controller groups 106 includes any suitable structurefor controlling one or more aspects of a process system. As a particularexample, each controller in the controller groups 106 could represent acomputing device running a real-time operating system.

Redundant networks 108 are coupled to the controller groups 106. Thenetworks 108 facilitate interaction with the controller groups 106, suchas by transporting data to and from the controller groups 106. Thenetworks 108 could represent any suitable redundant networks. Asparticular examples, the networks 108 could represent a pair of Ethernetnetworks or a redundant pair of Ethernet networks, such as a FAULTTOLERANT ETHERNET (FTE) network from HONEYWELL INTERNATIONAL INC. Thenetworks 108 are often referred to as “supervisory” networks since thesenetworks transport data used to supervise the underlying “Level 1”controllers.

At least one switch/firewall 110 couples the networks 108 to twonetworks 112. The switch/firewall 110 may transport traffic from onenetwork to another. The switch/firewall 110 may also block traffic onone network from reaching another network. The switch/firewall 110includes any suitable structure for providing communication betweennetworks, such as a HONEYWELL CONTROL FIREWALL (CF9) device. Thenetworks 112 could represent any suitable networks, such as a pair ofEthernet networks or an FTE network.

In the Purdue model, “Level 2” may include one or more machine-levelcontrollers 114 coupled to the networks 112. The machine-levelcontrollers 114 perform various functions to support the operation andcontrol of the controller groups 106, sensors 102, and actuators 103,which could be associated with a particular piece of industrialequipment (such as a boiler or other machine). For example, themachine-level controllers 114 could log information collected orgenerated by the controller groups 106, such as measurement data fromthe sensors 102 or control signals for the actuators 103. Themachine-level controllers 114 could also execute applications thatcontrol the operation of the controller groups 106, thereby controllingthe operation of the actuators 103. In addition, the machine-levelcontrollers 114 could provide secure access to the controller groups106. Each of the machine-level controllers 114 includes any suitablestructure for providing access to, control of, or operations related toa machine or other individual piece of equipment. Each of themachine-level controllers 114 could, for example, represent a servercomputing device running a MICROSOFT WINDOWS operating system. Althoughnot shown, different machine-level controllers 114 could be used tocontrol different pieces of equipment in a process system (where eachpiece of equipment is associated with one or more controller groups 106,sensors 102, and actuators 103).

One or more operator stations 116 are coupled to the networks 112. Theoperator stations 116 represent computing or communication devicesproviding user access to the machine-level controllers 114, which couldthen provide user access to the controller groups 106 (and possibly thesensors 102 and actuators 103). As particular examples, the operatorstations 116 could allow users to review the operational history of thesensors 102 and actuators 103 using information collected by thecontroller groups 106 and/or the machine-level controllers 114. Theoperator stations 116 could also allow the users to adjust the operationof the sensors 102, actuators 103, controller groups 106, ormachine-level controllers 114. In addition, the operator stations 116could receive and display warnings, alerts, or other messages ordisplays generated by the controller groups 106 or the machine-levelcontrollers 114. Each of the operator stations 116 includes any suitablestructure for supporting user access and control of one or morecomponents in the system 100. Each of the operator stations 116 could,for example, represent a computing device running a MICROSOFT WINDOWSoperating system.

At least one router/firewall 118 couples the networks 112 to twonetworks 120. The router/firewall 118 includes any suitable structurefor providing communication between networks, such as a secure router orcombination router/firewall. The networks 120 could represent anysuitable networks, such as a pair of Ethernet networks or an FTEnetwork.

In the Purdue model, “Level 3” may include one or more unit-levelcontrollers 122 coupled to the networks 120. Each unit-level controller122 is typically associated with a unit in a process system, whichrepresents a collection of different machines operating together toimplement at least part of a process. The unit-level controllers 122perform various functions to support the operation and control ofcomponents in the lower levels. For example, the unit-level controllers122 could log information collected or generated by the components inthe lower levels, execute applications that control the components inthe lower levels, and provide secure access to the components in thelower levels. Each of the unit-level controllers 122 includes anysuitable structure for providing access to, control of, or operationsrelated to one or more machines or other pieces of equipment in aprocess unit. Each of the unit-level controllers 122 could, for example,represent a server computing device running a MICROSOFT WINDOWSoperating system. Although not shown, different unit-level controllers122 could be used to control different units in a process system (whereeach unit is associated with one or more machine-level controllers 114,controller groups 106, sensors 102, and actuators 103).

Access to the unit-level controllers 122 may be provided by one or moreoperator stations 124. Each of the operator stations 124 includes anysuitable structure for supporting user access and control of one or morecomponents in the system 100. Each of the operator stations 124 could,for example, represent a computing device running a MICROSOFT WINDOWSoperating system.

At least one router/firewall 126 couples the networks 120 to twonetworks 128. The router/firewall 126 includes any suitable structurefor providing communication between networks, such as a secure router orcombination router/firewall. The networks 128 could represent anysuitable networks, such as a pair of Ethernet networks or an FTEnetwork.

In the Purdue model, “Level 4” may include one or more plant-levelcontrollers 130 coupled to the networks 128. Each plant-level controller130 is typically associated with one of the plants 101 a-101 n, whichmay include one or more process units that implement the same, similar,or different processes. The plant-level controllers 130 perform variousfunctions to support the operation and control of components in thelower levels. As particular examples, the plant-level controller 130could execute one or more manufacturing execution system (MES)applications, scheduling applications, or other or additional plant orprocess control applications. Each of the plant-level controllers 130includes any suitable structure for providing access to, control of, oroperations related to one or more process units in a process plant. Eachof the plant-level controllers 130 could, for example, represent aserver computing device running a MICROSOFT WINDOWS operating system.

Access to the plant-level controllers 130 may be provided by one or moreoperator stations 132. Each of the operator stations 132 includes anysuitable structure for supporting user access and control of one or morecomponents in the system 100. Each of the operator stations 132 could,for example, represent a computing device running a MICROSOFT WINDOWSoperating system.

At least one router/firewall 134 couples the networks 128 to one or morenetworks 136. The router/firewall 134 includes any suitable structurefor providing communication between networks, such as a secure router orcombination router/firewall. The network 136 could represent anysuitable network, such as an enterprise-wide Ethernet or other networkor all or a portion of a larger network (such as the Internet).

In the Purdue model, “Level 5” may include one or more enterprise-levelcontrollers 138 coupled to the network 136. Each enterprise-levelcontroller 138 is typically able to perform planning operations formultiple plants 101 a-101 n and to control various aspects of the plants101 a-101 n. The enterprise-level controllers 138 can also performvarious functions to support the operation and control of components inthe plants 101 a-101 n. As particular examples, the enterprise-levelcontroller 138 could execute one or more order processing applications,enterprise resource planning (ERP) applications, advanced planning andscheduling (APS) applications, or any other or additional enterprisecontrol applications. Each of the enterprise-level controllers 138includes any suitable structure for providing access to, control of, oroperations related to the control of one or more plants. Each of theenterprise-level controllers 138 could, for example, represent a servercomputing device running a MICROSOFT WINDOWS operating system. In thisdocument, the term “enterprise” refers to an organization having one ormore plants or other processing facilities to be managed. Note that if asingle plant 101 a is to be managed, the functionality of theenterprise-level controller 138 could be incorporated into theplant-level controller 130.

Access to the enterprise-level controllers 138 may be provided by one ormore operator stations 140. Each of the operator stations 140 includesany suitable structure for supporting user access and control of one ormore components in the system 100. Each of the operator stations 140could, for example, represent a computing device running a MICROSOFTWINDOWS operating system.

A historian 141 is also coupled to the network 136 in this example. Thehistorian 141 could represent a component that stores variousinformation about the system 100. The historian 141 could, for example,store information used during production scheduling and optimization.The historian 141 represents any suitable structure for storing andfacilitating retrieval of information. Although shown as a singlecentralized component coupled to the network 136, the historian 141could be located elsewhere in the system 100, or multiple historianscould be distributed in different locations in the system 100.

As described above, lower-level controllers (such as Level 1 controllersin the controller groups 106) communicate with the sensors 102 andactuators 103 over one or more industrial control networks 105. Thelower-level controllers also communicate with higher-level controllersor other devices/systems over one or more supervisory networks 108.

Controllers at Level 1 of the Purdue model therefore often need tocommunicate over multiple types of networks. For various reasons,industrial process control and automation systems often need tosegregate the traffic over industrial control networks from the trafficover supervisory networks. The segregation may be needed for variousreasons, such as high availability, network protocol conflict,performance, or other reasons related to the networks or thecontrollers. Also, it is often necessary or desirable to maintainredundancy of both networks and controllers, which helps to ensure thatno single point of failure renders part of a process system unreachable.However, industrial control networks and supervisory networks oftensupport redundancy mechanisms that are different or that conflict withone another.

In accordance with this disclosure, as described in more detail below,each controller group 106 includes redundant controllers used tosegregate the industrial control and supervisory networks 105, 108. Forexample, each controller group 106 could include at least fourcontrollers. At least two controllers can be connected to the industrialcontrol networks 105 and function as redundant controllers that interactwith sensors and actuators. At least two other controllers can beconnected to the supervisory networks 108 and function as redundantcontrollers that interact with higher-level controllers. In addition,the controllers in the controller group 106 can communicate with oneanother using a private network. In particular embodiments, thecontrollers in a controller group 106 and the private network could allbe located within a single cabinet, and the private network may not beaddressable or accessible from any private or public network.

In this way, redundant controllers can be provided for both thesupervisory and industrial control networks, helping to increase thereliability of control operations for a process system. Moreover, sincedifferent controllers are connected to different networks, segregationof network traffic can be done more easily and reliably. Further,communications between controllers can occur over a private network thatcan be secured, helping to ensure the reliability and security ofinter-controller communications. In addition, when the controllers andprivate network are implemented using a common set of hardware, this canincrease the ease of various functions such as spare parts management,failure/repair maintenance, installation, mounting, and power systemmanagement.

Although FIG. 1 illustrates one example of an industrial process controland automation system 100, various changes may be made to FIG. 1. Forexample, a control system could include any number of sensors,actuators, controllers, servers, operator stations, and networks. Also,the makeup and arrangement of the system 100 in FIG. 1 is forillustration only. Components could be added, omitted, combined, furthersubdivided, or placed in any other suitable configuration according toparticular needs. Further, particular functions have been described asbeing performed by particular components of the system 100. This is forillustration only. In general, process control systems are highlyconfigurable and can be configured in any suitable manner according toparticular needs. In addition, FIG. 1 illustrates an example environmentin which UMCs can be used. This functionality can be used in any othersuitable device or system.

FIG. 2 illustrates an example UMC 104 according to this disclosure. TheUMC 104 could, for example, denote the UMC 104 in FIG. 1 used toimplement the industrial process control and automation system 100.However, the UMC 104 could be used in any other suitable system.

As shown in FIG. 2, the UMC 104 includes at least one processor 202, atleast one storage device 204, at least one communications unit 206, atleast one input/output (I/O) interface 208, and at least onecustomizable programmable interface 209. Each processor 202 can executeinstructions, such as those that may be loaded into a memory 210. Eachprocessor 202 denotes any suitable processing device, such as one ormore microprocessors, microcontrollers, digital signal processors,application specific integrated circuits (ASICs), field programmablegate arrays (FPGAs), or discrete circuitry. In some embodiments, theprocessor 202 has redundancy in the form of other processors 202.

The memory 210 and a persistent storage 212 are examples of storagedevices 204, which represent any structure(s) capable of storing andfacilitating retrieval of information (such as data, program code,and/or other suitable information on a temporary or permanent basis).The memory 210 may represent a random access memory or any othersuitable volatile or non-volatile storage device(s). The persistentstorage 212 may contain one or more components or devices supportinglonger-term storage of data, such as a read only memory, hard drive,Flash memory, or optical disc.

The communications unit 206 supports communications with other systemsor devices. For example, the communications unit 206 could include atleast one network interface card or wireless transceiver facilitatingcommunications over at least one wired or wireless network. Thecommunications unit 206 may support communications through any suitablephysical or wireless communication link(s). For example, thecommunications unit 206 may facilitate communication with the cloud 142(for example, with a server device in the cloud 142). The communicationsunit 206 may transmit batch data or streaming data depending on thecompatibility of the cloud 142.

The I/O interfaces 208 allow for input and output of data. For example,the I/O interfaces 208 may provide for connection to meters or sensorssuch as sensors 102. To that end, the I/O interfaces 208 are compatiblewith multiple disparate data input types from disparate connectivityprotocols used in sensors and meters. The I/O interfaces 208 mayadditionally provide a connection for user input through a keyboard,mouse, keypad, touchscreen, or other suitable input device. The I/Ointerfaces 208 may also send output to a display, printer, or othersuitable output device. In some embodiments, one I/O interface 208 mayperform the above functions.

The customizable programmable interface 209 performs various functionson one or more inputs of the I/O interfaces 208. For example, thecustomizable programmable interface 209 can be used to process themultiple disparate input types received through the I/O interfaces 208and produce a single output. In this way, the customizable programmableinterface 209 can facilitate multiplexing of data from various sensorsand meters to an external source such as the cloud 142. Processing themultiple disparate inputs could include converting analog I/O to digitalI/O, converting both analog I/O and digital I/O to a universal I/O,interpolating data, and converting data from one connectivity protocolto another connectivity protocol. For example, data interpolation couldinclude pulse interpolation of an input from a turbine meter. In someembodiments, some or all of the functions of the customizableprogrammable interface 209 are performed by the processor 202.

Although FIG. 2 illustrates one example of a UMC 104, various changesmay be made to FIG. 2. For example, various components in FIG. 2 couldbe combined, further subdivided, rearranged, or omitted and additionalcomponents could be added according to particular needs. In addition,computing devices come in a wide variety of configurations, and FIG. 2does not limit this disclosure to any particular configuration ofcomputing device.

FIG. 3 illustrates an example UMC 104 connected to a metering systemaccording to this disclosure. For ease of explanation, the UMC 104 isdescribed as being used in the industrial process control and automationsystem 100 of FIG. 1. Additionally, the UMC 104 is described as beingused with a gas metering system. However, the UMC 104 could be used inany other suitable system.

As shown in FIG. 3, the UMC 104 receives inputs from one or more sensors102, which in this example are gas metering sensors. In the example ofgas metering, the sensors 102 include a flow meter 102 a, a pressuresensor (or meter) 102 b, a temperature sensor (or meter) 102 c, and agas chromatograph 102 d. In this example, the sensors 102 arepre-existing sensors installed in the industrial process control andautomation system 100. That is, the sensors 102 were not necessarilydesigned to interface with the UMC 104. The UMC 104 is capable ofreceiving and interpreting the multiple disparate data types from thevarious sensors 102.

The UMC 104 is compatible with the disparate output types of the sensors102, such as Q_(flow) of the flow meter 102 a, P_(T) of the pressuresensor 102 b, T_(T) of the temperature sensor 102 c, and Gas Quality ofthe gas chromatograph 102 d. This data could be analog or digital,depending on the meter or sensor. The UMC 104 is also able to receiveadditional data from the sensors 102 via new digital links to thepre-existing sensors. For example, this data could include diagnosticdata from the meters or sensors 102 that is not traditionally used inanalysis of the meter or sensor data. In some embodiments, thediagnostic data can be extracted from the standard outputs of the metersor sensors 102, for example using the customizable programmableinterface 209 of the UMC 104, while in other embodiments the diagnosticdata is received via a separate input from one or more of the meters orsensors 102. In some embodiments, the UMC 104 additionally receives datafrom other sensors 302 in the environment of the sensors 102. That is,the sensors 302 may be other sensors that are part of the system 100,but that are not directly interfaced with the sensors 102.

The UMC 104, after transforming the disparate data from sensors 102 and302 into compatible data, which may be called data cleansing or datawrangling, transmits the resulting data either as a stream or in batchesto the cloud 142. The data may be transmitted in various ways, such asthrough an industrial wireless network 304, through a fiber cable link306, or through existing industrial connectivity links 308. Examples ofindustrial wireless networks 304 include WIRELESSHART, ISA 100.11a, andIEEE 802.11. Examples of existing industrial connectivity links 308include HART, FIELDBUS, MODBUS, and OPC. This connection to the cloudmay be referred to as an industrial internet of things (IIoT) gateway,as the UMC 104 may be considered part of the IIoT. In some embodiments,the transmissions are made through a secure link that includes, forexample, encryption of the data before transmission to the cloud 142.

Although FIG. 3 illustrates an example UMC 104 connected to a meteringsystem, various changes may be made to FIG. 3. For example, more orfewer sensors 102 or 302 could be connected to the UMC 104. Also, anysuitable number of UMCs 104 could be used to monitor various sets ofsensors 102. Furthermore, the sensors 102 that are described as gasmetering sensors can measure any other fluid.

FIG. 4 illustrates an example process flow 400 using the UMC 104 to senddata to the cloud and perform data cleansing, data wrangling,measurement validation, and prognostication according to thisdisclosure. For ease of explanation, the process flow 400 is describedas being used in the system 100 of FIG. 1. The process flow 400 could beused in any other suitable system.

As shown in FIG. 4, the process flow 400 begins with a set of sensors102 that include, in this example, a flow meter 102 a, pressure sensor102 b, temperature sensor 102 c, and an analyzer (such as gaschromatograph 102 d, that provides fluid density or fluid compositiondata). The data from the sensors 102 is input to a flow computer 402,and simultaneously is captured by the UMC 104. The flow computer 402outputs bulk flow rate through the flow meter 102 a, integratedtotalization over pre-defined periods of time, recording any notifiedalarms, and any mismeasurement events within the sensors 102.

The data from the flow computer 402 is output to a metering supervisorycomputer (MSC) 404, which manages data from a plurality of flowcomputers 402 (although only one flow computer 402 is illustrated). TheMSC 404 hands over flow rate data to a distributed control system (DCS)406 that subsequently records data in process historians (such ashistorian 141) and reports the data to management enterprise systems.However, condition-based uncertainty inherent in the flow meter 102 a isnot captured by the flow computer 402 or the MSC 404, and externalvalidation of the integrity of the flow meter 102 a is useful. The datacaptured by the UMC 104 can be used to perform such validation, as willbe further described below.

The UMC 104 may operate as described above with respect to FIGS. 2 and3, and may provide data through an IIoT gateway to a cloud, such ascloud 142. In this example, the cloud 142 includes the physical meteringinformation received from the UMC 104, which includes data from thesensors 102. The data received from the UMC 104 is denoted as PM1 toPMn, and represents data from physical meters.

Additionally, data from other parts of the same plant, such as otherparts of plant 101 a, may be contained in disparate databases or cloudinstances 408. In some embodiments, the disparate databases or cloudinstances 408 include process historians such as historian 141. Thisdata is imported into the process flow through the cloud as representedby cloud 410. In this example, data describing processes is denoted asdata B1 to Bn, data related to sensors in the process flows of processesB1 to Bn (for example, sensors in other parts of plant 101 a) is denotedas 1 to n, and data from the plant is denoted as A1 to An (for example,this data could correspond to expected flow parameters of processeswithin the plant).

The above disparate data is handled by the data cleansing or datawrangling process 412. Data cleansing (also called data scrubbing) isthe process of amending or removing data in a database that isincorrect, incomplete, improperly formatted, or duplicated. Datawrangling is the process of cleaning and unifying data sets for ease ofaccess and analysis, and can include converting or mapping data from oneraw form into another format for more convenient consumption andorganization of the data. In some embodiments, the data that is input tothe data cleansing or data wrangling process 412 is first loaded fromthe clouds 142 and 410 (which may be referred to as cloud instances)into connected instances 416, 418, and 420 which represent, for example,local copies of the disparate data from the clouds 142 and 410 on amachine or machines that execute the data cleansing or data wranglingprocess 412.

After importing the above data, the data cleansing or data wranglingprocess 412 begins with understanding and documenting the data sourcesand their limitations, which may be referred to as compiling domainknowledge. This includes, for example, determining and documenting thatdata PM1 to PMn comes from the physical meters or sensors 102 within aplant 101 a, that data B1 to Bn comes from other processes within aplant 101 a, that data 1 to n comes from other sensors within a plant101 a, and that data A1 to An comes from plants 101 a to 101 n. Next,the data cleansing or data wrangling process 412 cleans up duplicatedata, blank data, and other simple errors within the imported data sets.The disparate data is then combined into a single destination data typeusing the domain knowledge. In some embodiments the data cleansing ordata wrangling process 412 then interpolates new data by calculating newfields and re-categorizing data (for example, using creativeintelligence to imagine derivative variables based on the importeddata). The data cleansing or data wrangling process 412 then processesthe resulting data to remove outliers and “calculated-bad” results. Thisprovides validated results.

In the example of FIG. 4, the data cleansing or data wrangling process412 receives the disparate data sets PM1 to PMn, B1 to Bn, A1 to An, and1 to n. The data within each disparate set are then compared to eachother to determine whether simple errors exist within the data set, forexample duplication of data or blanks in data. These errors arecorrected, for example by removing duplicates and blanks in the dataset. Disparate data sets are then combined based on their relationshipto each other, such as by combining subsets of data related to a processinto a master set of data for that process, and by combining data formultiple processes into a master set of data for the plant. Formetering, this combination of disparate data sets includes adding orsubtracting meter values and in some cases inferring data. For example,if PM1 represents a physical flow meter (such as flow meter 102 a) in aprocess pipe that splits into two smaller streams represented by processdata 1B and 2B (which may also be referred to as flow data for thisprocess), the process can infer that 1B+2B=PM1 (i.e., that 1B and 2B aresubsets of data that combine into PM1). However, in this example therelationship between 1B and 2B is not known, as there is no physicalflow meter data for 1B and 2B. It is possible that the pipes related tosub-processes associated with 1B and 2B are different sizes or haveother differing properties.

In order to interpolate the flow meter data for processes 1B and 2B,data is sent to the virtual meter 422. In some embodiments, the virtualmeter 422 may be implemented as part of the data cleansing or datawrangling process 412, or vice versa. The virtual meter 422 is a virtualmodel of a meter that uses process or plant data to estimate a measurand(e.g., flow rate) where there is no physical meter in place, or tosubstitute for a physical meter that is taken offline (e.g., formaintenance or during a fault condition of the physical meter). That is,the virtual meter 422 allows a process to function as if a correspondingphysical meter were installed in the process flow.

In one example, the virtual meter 422 applies computational fluiddynamics (CFD) to both unknowns such as 1B and 2B, and to known data,such as the physical meter data PM1, the sensor data 1 to n (which inthis example represents sensor data from non-flow sensors attributed tothe piping of processes 1B and 2B), and data on plant features such asthe pipe geometry of the pipes associated with processes 1B and 2B. Thevirtual meter 422 uses CFD on this data to construct a virtual model ofa flow meter for processes 1B and 2B based on the knowledge that1B+2B=PM1. From this point, the virtual meter 422 can be used togenerate the data for processes 1B and 2B. Furthermore, using the inputdata from the other portions of the plant, uncertainty analysis can beapplied to the virtual meter 422 in the same way that it is applies tophysical sensors 102, providing the process data 1B and 2B along withtheir associated uncertainty values.

The virtual meter 422 is used in conjunction with the data cleansing ordata wrangling process 412 to fill out any missing data in the inputdata sets until a valid and complete “master” data set for the plant isconstructed. This means that the combined data sets related to allprocesses of the plant (i.e., B1 to Bn and 1 to n) match with thecombined data set Al to An that represents an expected mass balancingacross the plant, with associated condition-based uncertainty values.The virtual meter 422 therefore provides the benefits of a physicalmeter along with enhanced process validation, leveraging an autonomouslyself-maintaining virtual meter model that can be checked based onprocess or plant historian data, and other physical sensors or physicalmeters in the plant.

Furthermore, the physical meter data PM1 to PMn is provided by the datacleansing or data wrangling process 412 to the virtual digital twin 424.Recalling that PM1 to PMn represent data from sensors such as flowmeters 102 a and data from the environment around the flow meters 102 a(such as the pressure sensors 102 b, the temperature sensors 102 c, andanalyzers (or gas chromatographs) 102 d, the virtual digital twin 424 isconstructed based on the data PM1 to PMn to be a virtual representationof the physical flow meters such as flow meter 102 a after taking theenvironment of the flow meters into context.

The virtual digital twin 424 is then able to provide output data DT1 toDTn that tracks the behavior of corresponding physical meters (i.e., thevalue of DT1 should equal PM1, DT2 should equal PM2, etc.). This outputdata DT1 to DTn can be used with the virtual metering data VM1 to VMn toprovide prognostics modeling analysis 426. Specifically, the array ofdata from the data cleansing or data wrangling process 412 allows theprognostics modeling analysis 426 to make connections between previouslydisparate data to predict anomalies. For example, the prognosticsmodeling analysis 426 includes prediction of variances within datareceived from physical sensors 102. That is, the prognostics modelinganalysis 426 cooperates with the virtual digital twin 424 to simulate“what-if” scenarios in the virtual digital twin 424, generatingsimulated output data that points to the corresponding physical meter(such as flow meter 102 a) generating an anomaly. For example, theprognostics modeling analysis 426 can contain or receive records ofvalid metering values (for example, VM1 to VMn), and may compare thecombination of DT1 to DTn and VM1 to VMn to determine if the combinationresults in valid metering values. If not, an anomaly is detected in thesimulation, which predicts an anomaly in the installed system.

The prognostics modeling analysis 426 also cooperates with the virtualmeter 422 to perform mass balancing between the simulated scenario ofthe virtual digital twin 424 (i.e., the outputs DT1 to DTn for thesimulated scenario) and the output data VM1 to VMn of the virtual meter422 to determine the source of the predicted anomaly. Outputs of theprognostics modeling analysis 426 can include an indication of apredicted anomaly and a determined source of the predicted anomaly. Thiscould take the form of a failure flag for a particular piece ofequipment, such as a meter, where the failure flag indicates thatmaintenance should be performed before the predicted anomaly occurs. Theoutput of the prognostics modeling analysis 426 can also include anindication that no anomalies are predicted (i.e., that all predictedvirtual meter values are valid and no anomalies are prognosticated).

The output of the prognostics modeling analysis 426 is sent to the DCS406, enabling the DCS 406 to take action to preemptively correct for theanomaly before it occurs. Because the anomaly is predicted rather thandetected after occurring, plant management is able to schedulemaintenance on the source of the predicted anomaly with minimal impacton the plant.

In some embodiments, while the portion of the process that is thedetermined source of the predicted anomaly is taken offline formaintenance, a virtual digital twin 424 may be substituted in its place,providing continued virtual metering of the component based on thecontinued input of other sensors in the environment of the offlinecomponent. In this way, downtime may be avoided completely in caseswhere the process does not need to be shut down to take the componentoffline for maintenance or repairs (for example, when the repair is on ameter or sensor rather than a pipe, valve, or other component involvedin processing). Once the physical component is repaired and brought backonline, the outputs of the physical component can be compared to itsvirtual digital twin 424 to determine whether the output of the physicalcomponent is correct.

Returning to the data cleansing or data wrangling process 412, thephysical meter data PM1 to PMn that was captured by the UMC 104 (fromsensors such as sensor 102), as well as relevant data from the processthat sensors are placed in (for example, data from historian 141 thatrelates to historical performance of the sensors) is sent to CBM andnear real-time condition-based uncertainty analysis 428 after cleansingby the data cleansing or data wrangling process 412. CBM and nearreal-time condition-based uncertainty analysis 428 performs CBM anddetermines an uncertainty (e.g., + or −%) for the physical meter datausing the supplied data. Because the physical meter data is continuouslystreaming (or, in some embodiments, being periodically batched) from theUMC 104, the CMB and condition-based uncertainty analysis is producedand updated in near real-time. The output of the CBM and near real-timecondition-based uncertainty analysis 428 is denoted as PM1+/−X% toPMn+/−X%, which represents the physical meter data of sensor 102 withits uncertainty. Built into the uncertainty is an indication of thecondition of the sensor 102. In some embodiments, a further indicator ofthe uncertainty (e.g., a flag that re-calibration is recommended) couldbe included in the output.

The output of the CBM and near real-time condition-based uncertaintyanalysis 428 also serves as validation of the sensor 102's output.Specifically, it indicates the condition (or health) of the sensor orsensors under review as well as how much the reading from the sensor mayvary from the actual state of the measurand. If the condition of thesensor is determined to be good, and the uncertainty is below athreshold, then the resulting value (e.g., PM1+/−X%) is a validatedreading of the sensor (e.g., the data PM1 captured from a sensor 102).

The validated data 430, which in this example references only flowratedata, could also include any other relevant process data. The validateddata 430 is sent through an IIoT gateway 432 to a technical auditprocess 434 within the system that contains the sensors 102 a-d. Thetechnical audit process 434 also receives data from the MSC 404,described above, which represents the standard output from sensors suchas the sensors 102 a-d. The technical audit process 434 compares therelevant validated data 430 with the output of the MSC 404 to confirmwhether the validated data 430 matches the output from the MSC 404. Theresults of the technical audit process 434 are then sent to DCS 406,allowing further review by plant personnel takes place in order todetermine any appropriate actions that should be taken based on themeasurements of sensors 102 a-d.

Although FIG. 4 illustrates one example of a process flow 400 using aUMC 104 and analysis in a cloud, various changes may be made to FIG. 4.For example, various components in FIG. 4 could be combined, subdivided,or omitted and additional components could be added according toparticular needs. Also, the process flow 400 could include additionalsets of sensors 102 feeding into additional flow computers 402 that inturn feed into MSC 404. These additional sets of sensors 102 couldconnect to additional UMCs 104 that feed data into the data cleansing ordata wrangling process 412 for use with CBM and near real-timecondition-based uncertainty analysis 428 as well as prognostics modelinganalysis 426.

FIG. 5 illustrates a mesh connected metering ecosystem 500 according tothis disclosure. As shown in FIG. 5, the mesh connected meteringecosystem 500 is conceptually separated into nested data connectivity(DC) levels: a connected metering instance 502 (DC_01), a connectedprocess instance 504 (DC_02), and a connected plant instance 506(DC_03). It is understood that multiple connected metering instances 502can be contained within a connected process instance 504, and thatmultiple connected process instances 504 can be contained within aconnected plant instance 506.

The connected metering instance 502 represents a cloud ecosystem thatincludes sensors 102 a-d that feed into a CBM and near real-timecondition-based uncertainty analysis 428. The sensors 102 a-d and theCBM and near real-time condition-based uncertainty analysis 428 all feedinto a universal input/output (I/O) 508 that takes the place of the flowcomputer 402 and MSC 404. The universal I/O 508 connects all of the meshconnected metering ecosystem 500 together in a cloud for analysis. Thatis, it connects all connected metering instances 502 that are presentwithin a plant into the mesh connected metering ecosystem 500 for theplant. The multiple connected process instances 504 and connected plantinstance 506 are conceptual groupings of connected metering instances502 within the plant. In this way, overlap between traditional remoteterminal units (RTU), programmable logic controllers (PLC), supervisorycontrol and data acquisition (SCADA), and DCS can be eliminated,simplifying and saving costs.

Data from all parts of the mesh connected metering ecosystem 500 that iscollected via the universal I/O 508 is made compatible by the universalI/O in a similar manner to the data cleansing or data wrangling process412 of FIG. 4. In some embodiments, the data cleansing or data wranglingprocess 412 may be implemented in the cloud of the mesh connectedmetering ecosystem 500 for this purpose.

Data from various parts of the mesh connected metering ecosystem 500 canbe used to perform virtual metering model 510, which uses the array ofdata collected from different connected process instances 504 anddifferent connected metering instances 502, and to a lesser extent fromthe plant instance 506, to estimate measurands in place of a physicalmeter such as one of sensors 102 a-d. Similarly, data from a connectedmetering instance 502 can be used to create virtual digital twins 512 ofany given sensor in the connected metering instance 502. The virtualmetering model 510 and virtual digital twin 512 could work similarly tovirtual metering 422 and virtual digital twin 424 of FIG. 4.Accordingly, the virtual metering model 510 and virtual digital twin 512can be used to provide prognostic analysis for meters in the meshconnected metering ecosystem 500.

FIG. 6 illustrates an example method 600 of a connected metering processaccording to this disclosure. For ease of explanation, the method 600 isdescribed with reference to the process flow 400 of FIG. 4. The method600 could be used with any other suitable process flow or system.

Beginning at block 602, at least two data streams are received at a UMC,such as UMC 104, from at least two sensors, such as sensors 102 a-d.Each of the data streams can have a disparate connectivity protocol, asdescribed above. In some embodiments, one or more of the data streamsmay share a connectivity protocol. In this example, the at least twosensors are installed in the same process.

At block 604, the UMC converts the connectivity protocol of each of thereceived data streams into one uniform connectivity protocol. In someembodiments, the data streams are converted into a new connectivityprotocol that none of them previously shared. In other embodiments, thedata streams are converted into the connectivity protocol of one of thedata streams. The connectivity protocol can include at least one ofanalog I/O, digital I/O, or a universal I/O. In some embodiments,converting the data streams into the new connectivity protocol includesperforming pulse interpolation using pulses from each of the at leasttwo data streams.

At block 606, the UMC transmits a combined data stream comprising the atleast two data streams with the uniform connectivity protocol. The UMCmay transmit the data stream to a cloud server, such as a server incloud 142.

At block 608, a cloud server receives, from the UMC, at least one datastream that includes data from the at least two sensors. In someembodiments, one data stream is received from the UMC 104, and otherdata streams from other sensors are received from other UMCs. In someembodiments, the data streams are received from another cloud serverthat, in turn, receives them from the UMC or UMCs.

At block 610, the cloud server receives, from at least one other server,data related to an environment around the at least two sensors. In someembodiments, this data comes from one or more other cloud servers, andthe data comprises data from the process surrounding the above at leasttwo sensors. For example, this data could include data from sensors 302,data related to pipe geometry in the process, or the like.

At block 612, the cloud server performs data cleansing or data wranglingon the data stream received from the UMC and the data received from theother server or servers to generate validated data. Data cleansing ordata wrangling includes determining a source of the at least one datastream received from the UMC (e.g., the sensors that are the source ofthe data) and a source of the data related to the environment around theat least two sensors (e.g., data related to the pipe geometry of theprocess).

Data cleansing or data wrangling further includes removing duplicate andblank data from the at least one data stream received from the UMC andthe data related to the environment around the at least two sensors, andcombining the data from the at least one data stream received from theUMC and the data related to the environment around the at least twosensors into combined data. In some embodiments, data cleansing or datawrangling further includes interpolating new data from the combined dataand adding the new data to the combined data by calculating new fieldsand re-categorizing data using derivative variables based on thecombined data and removing outliers and bad results from the combineddata to generate validated data.

At block 614, the cloud server performs prognostic modeling on thevalidated data. Prognostic modeling includes simulating a meteringscenario on a virtual digital twin of one of the at least two sensors togenerate simulated output data that corresponds to a potential output ofthe one of the at least two sensors under the metering scenario.Prognostic modeling further includes determining existence of an anomalyin the simulated output data by receiving virtual sensor data from atleast one virtual sensor that corresponds to the environment around theat least two sensors, and comparing the simulated output data to thevirtual sensor data to determine if the simulated output data is valid.

At block 616, the cloud server transmits a result of the prognosticmodeling to a distributed control system (DCS). The DCS can then use theprognostic model data to control plant processes. For example, the DCScould flag a sensor, process, or other equipment for maintenance basedon an indication in the prognostic model that a failure (i.e., ananomaly) will occur.

Although FIG. 6 illustrates one example method of a connected meteringprocess, various changes may be made to FIG. 6. For example, while FIG.6 discusses prognostic modeling focused on a set of physical sensorswithin a particular process of a plant, the prognostic modeling could beperformed for any number of physical sensors in the plant. Indeed,prognostic modeling could be performed for the entire plant.

In some embodiments, various functions described above are implementedor supported by a computer program that is formed from computer readableprogram code and that is embodied in a computer readable medium. Thephrase “computer readable program code” includes any type of computercode, including source code, object code, and executable code. Thephrase “computer readable medium” includes any type of medium capable ofbeing accessed by a computer, such as read only memory (ROM), randomaccess memory (RAM), a hard disk drive, a compact disc (CD), a digitalvideo disc (DVD), or any other type of memory. A “non-transitory”computer readable medium excludes wired, wireless, optical, or othercommunication links that transport transitory electrical or othersignals. A non-transitory computer readable medium includes media wheredata can be permanently stored and media where data can be stored andlater overwritten, such as a rewritable optical disc or an erasablememory device.

It may be advantageous to set forth definitions of certain words andphrases used throughout this patent document. The terms “application”and “program” refer to one or more computer programs, softwarecomponents, sets of instructions, procedures, functions, objects,classes, instances, related data, or a portion thereof adapted forimplementation in a suitable computer code (including source code,object code, or executable code). The terms “include” and “comprise,” aswell as derivatives thereof, mean inclusion without limitation. The term“or” is inclusive, meaning and/or. The phrase “associated with,” as wellas derivatives thereof, may mean to include, be included within,interconnect with, contain, be contained within, connect to or with,couple to or with, be communicable with, cooperate with, interleave,juxtapose, be proximate to, be bound to or with, have, have a propertyof, have a relationship to or with, or the like. The phrase “at leastone of,” when used with a list of items, means that differentcombinations of one or more of the listed items may be used, and onlyone item in the list may be needed. For example, “at least one of: A, B,and C” includes any of the following combinations: A, B, C, A and B, Aand C, B and C, and A and B and C.

While this disclosure has described certain embodiments and generallyassociated methods, alterations and permutations of these embodimentsand methods will be apparent to those skilled in the art. Accordingly,the above description of example embodiments does not define orconstrain this disclosure. Other changes, substitutions, and alterationsare also possible without departing from the spirit and scope of thisdisclosure, as defined by the following claims.

1. A universal metering cabinet apparatus comprising: at least oneinput/output (I/O) interface configured to receive at least two datastreams, each of the at least two data streams received from one of atleast two sensors, and each of the at least two data streams having adifferent connectivity protocol; and wherein the at least oneinput/output (I/O) interface is configured to receive data from thesensors via digital links; a customizable programmable interface coupledwith the at least one I/O interface and configured to: transform thedata from the sensors into compatible data by data cleansing or datawrangling, and convert the connectivity protocol of each of the at leasttwo data streams into a same uniform connectivity protocol.
 2. Theuniversal metering cabinet apparatus of claim 1, wherein the at leasttwo sensors are each implemented in a same process.
 3. The universalmetering cabinet apparatus of claim 1, further comprising acommunications unit coupled to the customizable programmable interfaceand configured to transmit, to a server, a combined data streamcomprising the at least two data streams, the combined data streamhaving the same uniform connectivity protocol.
 4. The universal meteringcabinet apparatus of claim 3, wherein the communications unit is furtherconfigured to transmit the combined data stream as batched data.
 5. Theuniversal metering cabinet apparatus of claim 1, wherein thecustomizable programmable interface is configured to convert theconnectivity protocol of each of the received data streams into the sameuniform connectivity protocol by performing pulse interpolation usingpulses from each of the at least two data streams.
 6. The universalmetering cabinet apparatus of claim 1, wherein the same connectivityprotocol includes at least one of analog I/O, digital I/O, or auniversal I/O.
 7. A method comprising: receiving, at a universalmetering cabinet, at least two data streams, each of the at least twodata streams received from one of at least two sensors, and each of theat least two data streams having a different connectivity protocol,wherein the at least one input/output (I/O) interface is configured toreceive data from the sensors via digital links; transforming the datafrom the sensors into compatible data by data cleansing or datawrangling, and converting, using a customizable programmable interface,the connectivity protocol of each of the at least two data streams intoa same uniform connectivity protocol.
 8. The method of claim 7, whereinthe at least two sensors are each implemented in a same process.
 9. Themethod of claim 7, further comprising transmitting, to a server, acombined data stream comprising the at least two data streams, thecombined data stream having the same uniform connectivity protocol. 10.The method of claim 9, further comprising transmitting the combined datastream as batched data.
 11. The method of claim 7, further comprisingperforming pulse interpolation using pulses from each of the at leasttwo data streams.
 12. The method of claim 7, wherein the sameconnectivity protocol includes at least one of analog I/O, digital I/O,or a universal I/O.
 13. A method comprising: receiving at least one datastream that includes data from at least two sensors; receiving, from atleast one server, data related to an environment around the at least twosensors; performing data cleansing on the data stream and the data togenerate validated data; and performing prognostic modeling on thevalidated data wherein performing prognostic modeling comprises:determining the existence of an anomaly in the simulated output data andwherein determining the existence of an anomaly in the simulated outputdata comprises: receiving virtual sensor data from at least one virtualsensor that corresponds to the environment around the at least twosensors; and comparing the simulated output data to the virtual sensordata to determine if the simulated output data is valid.
 14. The methodof claim 13, wherein performing prognostic modeling comprises:simulating a metering scenario on a virtual digital twin of one of theat least two sensors to generate simulated output data that correspondsto a potential output of the one of the at least two sensors under themetering scenario.
 15. (canceled)
 16. The method of claim 13, whereinthe at least one virtual sensor is a virtual model of a physical sensorthat replicates functionality of the physical sensor for processes forwhich there is no physical sensor data.
 17. The method of claim 13,wherein performing data cleansing comprises: determining a source of theat least one data stream and a source of the data related to theenvironment around the at least two sensors; removing duplicate andblank data from the at least one data stream and the data related to theenvironment around the at least two sensors; and combining the data fromthe at least one data stream and the data related to the environmentaround the at least two sensors into combined data.
 18. The method ofclaim 17, wherein performing data cleansing further comprises:interpolating new data from the combined data and adding the new data tothe combined data; and removing outliers and bad results from thecombined data to generate validated data.
 19. The method of claim 18,wherein interpolating new data includes calculating new fields andre-categorizing data using derivative variables based on the combineddata.
 20. The method of claim 13, wherein receiving the at least onedata stream comprises receiving the at least one data stream from auniversal metering cabinet (UMC).